home *** CD-ROM | disk | FTP | other *** search
/ Animation How-To / Animation How-to CD.iso / PLY / ADDENDUM next >
Text File  |  1994-01-01  |  12KB  |  300 lines
  1. Last minute additions...
  2.  
  3. After getting the documents into shape for v1.5, I made several bug fixes and
  4. additions to make v1.6.  Rather than fix up the full document file (which will
  5. be done before the next release), this addendum file is provided to give
  6. information about the changes. The new features are:
  7.  
  8.    Depth mapped lights
  9.    Depth rendering (to save Z-Buffer information)
  10.    Displacement surfaces
  11.    Raw triangle vertex output
  12.    Directional light sources
  13.    Global haze
  14.    UV mapping and bounds
  15.    Hicolor display (VESA only, may not work right for you)
  16.    Texture maps and indexed textures
  17.    Summed textures
  18.    UV triangles
  19.    Static variables
  20.  
  21. I) Depth mapped lights and depth rendering
  22.  
  23. Depth mapped lights are very similar to spotlights, in the sense that they
  24. point from one location and at another information.  The primary use for these
  25. is for doing shadowing in scan converted scenes where shadow information
  26. might not be possible using the raytracer (see displacement surfaces). The
  27. format of their declaration is:
  28.  
  29.    depthmapped_light {
  30.       [ angle fexper ]
  31.       [ aspect fexper ]
  32.       [ at vexper ]
  33.       [ color expression ]
  34.       [ depth "depthfile.tga" ]
  35.       [ from vexper ]
  36.       [ hither fexper ]
  37.       [ up vexper ]
  38.       }
  39.  
  40. You may notice that the format of the declaration is very similar to the
  41. viewpoint declaration.  This is intentional, as you will usually generate
  42. the depth information for "depthfile.tga" as the output of a run of Polyray.
  43. To support output of depth information, a new statements was added to the
  44. viewpoint declaration.  The declaration to output a depth file would have the
  45. form:
  46.  
  47.    viewpoint {
  48.       from [ location of depth mapped light ]
  49.       at [ location the light is pointed at ]
  50.       ...
  51.       image_format 1
  52.       }
  53.  
  54. Where the final statement tells Polyray to output depth information instead of
  55. color information.  Note that if the value in the image_format statement is
  56. 0, then normal rendering will occur.  For an example of using a depth mapped
  57. light, see the file "room1.pi" in the data archives.
  58.  
  59. II) Displacement Surfaces
  60.  
  61. Displacement surfaces cause modification of the shape of an object as it
  62. is being rendered.  The amount and direction of the displacement are specified
  63. by an object modifier statement:
  64.  
  65.    displace vexper
  66.  
  67. Where the expression is a vector that tells Polyray how to do the displacement.
  68. This feature only works for scan converted images.  The raytracer will only
  69. see the undistorted surface.  For some examples of displacement surface, see
  70. the following files in the data archives:
  71.  
  72.    disp2.pi, disp3.pi, legen.pi, spikes.pi
  73.    
  74. III) Raw triangle vertex information
  75.  
  76. A somewhat odd addition to the image output formats for Polyray is the
  77. generation of raw triangle information.  What happens is very similar to the
  78. scan conversion process, but rather than draw polygons, Polyray will write
  79. a text description of the polygons (after splitting them into triangles).  The
  80. final output is a (usually long) list of lines, each line describing a single
  81. smooth triangle.  The format of the output is:
  82.  
  83. x1 y1 z1 x2 y2 z2 x3 y3 z3 nx1 ny1 nz1 nx2 ny2 nz2 nx3 ny3 nz3 u1 v1 u2 v2 u3 v3
  84.  
  85. The locations of the three vertices come first, the normal information for
  86. each of the vertices follows.  Lastly the uv values for each triangle are
  87. generated based on the surface you are rendering (see uv triangles below).
  88. Currently I don't have any applications for this output. The intent of this
  89. feature is to provide a way to build models in polygon form for conversion to
  90. another renderers' input format.
  91.  
  92. For example, to produce raw triangle output describing a sphere, and dump it
  93. to a file you could use the command:
  94.  
  95.    polyray sphere.pi -p z > sphere.tri
  96.  
  97. IV) Directional lights
  98.  
  99. The directional light means just that, light coming from some direction.  The
  100. biggest difference between this light source and the others is that no shadowing
  101. is performed.  This has pretty serious implications for shading, so if you
  102. use this type of light, you should also set the global shading flags so that
  103. surfaces are one-sided.  i.e. polyray foo.pi -q 55.  The format of the
  104. expression is:
  105.  
  106.    directional_light color, direction
  107.    directional_light direction
  108.  
  109. An example would be: directional_light <2, 3, -4>, giving a white light coming
  110. from the right, above, and behind the origin.
  111.  
  112. V) Global Haze
  113.  
  114. The global haze is a color that is added based on how far the ray travled before
  115. hitting the surface.  The format of the expression is:
  116.  
  117.    haze coeff, starting_distance, color
  118.  
  119. The color you use should almost always be the same as the background color.
  120. The only time it would be different is if you are trying to put haze into a
  121. valley, with a clear sky above (this is a tough trick, but looks nice).  A 
  122. example would be:
  123.  
  124.    haze 0.8, 3, midnight_blue
  125.  
  126. The value of the coeff ranges from 0 to 1, with values closer to 0 causing
  127. the haze to thicken, and values closer to 1 causing the haze to thin out.
  128. I know it seems backwards, but it is working and I don't want to break anything.
  129.  
  130. VI) UV mapping and bounds
  131.  
  132. In addition to the runtime variables x, y, P, etc.  the variables u and v
  133. have been added.  In general u varies from 0 to 1 as you go around an object
  134. and v varies from 0 to one as you go from the bottom to the top of an object.
  135. Not all primitives set meaningful values for u and v, those that do are:
  136.  
  137.    bezier, cone, cylinder, disc, sphere, torus, patch
  138.  
  139. These variables can be used in a couple of ways, to tell Polyray to only
  140. render portions of a surface within certain uv bounds, or they can be used
  141. as arguments to expressions in textures or displacement functions.
  142.  
  143. See the file uvtst.pi in the data archives for an example of using uv bounds
  144. on objects.  The file spikes.pi demonstrates using uv as variables in a
  145. displacement surface.  The file bezier1.pi demonstrates using uv as variables
  146. to stretch an image over the surface of a bezier patch.
  147.  
  148. VII) Hicolor display output
  149.  
  150. Polyray will support the VESA 640x480 hicolor graphics mode for display preview.
  151. The command line switch is "-V 2".  In polyray.ini, you would use
  152. "display hicolor".  Note that using any of the status display options can
  153. really screw up the picture.  I recommend "-t 0" if you are going to use
  154. this option.
  155.  
  156. Future versions will work better.  I just got a board that could handle hicolor,
  157. so I'm still experimenting.
  158.  
  159. VIII) Texture maps and indexed textures
  160.  
  161. A texture map is declared in a manner similar to color maps.  There is a
  162. list of value pairs and texture pairs, for example:
  163.  
  164.    define index_tex_map
  165.       texture_map([-2, 0, red_blue_check, bumpy_green],
  166.           [0, 2, bumpy_green, reflective_blue])
  167.  
  168. Note that for texture maps there is a required comma separating each of the
  169. entries.
  170.  
  171. These texture maps are complimentary to the indexed texture.  Two typical
  172. uses of indexed textures are to use solid texturing functions to select
  173. (and optinally blend) between complete textures rather than just colors, and
  174. to use image maps as a way to map textures to a surface.
  175.  
  176. For example, using the texture map above on a sphere can be done accomplished
  177. with the following:
  178.  
  179. object {
  180.    sphere <0, 0, 0>, 2
  181.    texture { indexed x, index_tex_map }
  182.    }
  183.  
  184. The indexed texture uses a lookup function (in this case a simple gradient
  185. along the x axis) to select from the texture map that follows.  See the
  186. data file "indexed1.pi" for the complete example.
  187.  
  188. As an example of using an image map to place textures on a surface, the
  189. following example uses several textures, selected by the color values in
  190. an image map.  The function "indexed_map" returns the color index value from
  191. a color mapped Targa image (or uses the red channel in a raw Targa).
  192.  
  193.    object {
  194.       sphere <0, 0, 0>, 1
  195.       texture {
  196.      indexed indexed_map(image("txmap.tga"), <x, 0, y>, 1),
  197.          texture_map([1, 1, mirror, mirror],
  198.                  [2, 2, bright_pink, bright_pink],
  199.                  [3, 3, Jade, Jade])
  200.      translate <-0.5, -0.5, 0> // center image
  201.